Highly available systems are designed to protect against network and operational failures. To support high availability (HA) in telephony networks, redundancy is built into each network element. Availability of a system is defined as the probability that the system provides correct Service delivery at a certain time ‘t’. Its a measure of correct service delivery with respect to the alternation of correct and incorrect service, measured by the probability A(t) that the system is ready to provide the service at a point in time t.
However, the Internet currently provides redundancy in the network as a whole rather than in each individual network element. In the Internet, the networks do not maintain states for individual user sessions. Rather, redundancy is provided through alternate routing paths in the Internet. In this instance, if a user sends a packet to another user the packet goes through the routing infrastructure. If a failure occurs in the network element, the path may not be active any more and the routing elements detect this failure and finds a suitable alternative path. This process takes time and the routing system performs self stabilization to overcome this failure.
The internet is a decentralised, fast growing network and it adapts itself to new changing requirements to incorporate new services such as voice over IP (internet protocol) (VoIP), virtual private network (VPN), quality of service (QoS) etc.
In addition, as wireless and Internet technologies converge, new requirements will need to emerge to support seamless real time services. This will place a very high demand on per hop packet processing on each network element in the Internet. To support the growing of such needs the network element needs to delivery high performance, and scalability. To meet these demands, networks elements such as routers have evolved from a monolithic software entity to distributed software and hardware entity. To support converged network service, network elements like routers may need to maintain per flow or per user information states to satisfy the service requirements. If such a network element fails, failover operation should be fast and the user of the service should notice no service distruption. Thus, each network elements in the Internet may need to provide high availability features in order to avoid disruption in the service. This suggests that network elements should support high availability features such as failover, load balancing, state replication etc.
Recent advancements in network processor technology have made it possible to present network functions as configurable and programmable modules.
The idea for establishing open interfaces in the control and forwarding plane enables a new building block approach in system architecture design which has demanded open interfaces for multi vendor operation. In this regard, reference is made to the network processing forum (www.npforum.org).
Network elements are provided with control cards and line cards. Routers or switches, which are based on a distributed architecture, are composed of one or more line cards and one or more control cards. A control card contains service logic and applications to perform control (signalling) and management of service functions. The control card typically contains one or more applications of logic to perform routing, QoS, security, mobility and charging services.
A line card in a distributed network element performs forwarding functions. It performs fast packet forwarding on a data path. In addition to forwarding, it also performs minimal signalling or filtering functions. Control cards provide instructions in the form of messages and program line card logic. The line card processes each incoming and outgoing packets and if any exceptions are encountered in a process a packet it will inform the control card. In order to provide a seamless continuous service, the control cards and line cards inside the network element need to synchronise amongst themselves and provide a single system viewed from the outside world. Although there are several standardisation efforts to provide higher availability in routing protocols, middleware and applications, they all make the assumption that the HA middleware is a single monolithic entity. The purpose of the middleware is to provide transparency. The following are middleware services.                High availability.        Access transparency (Location+network)        Database transparency        Fault tolerance etc.At the network processing forum NPF, efforts are being made to make open interfaces to the HA middleware itself and enable multiple vendor HA middleware components to interact to form a unified HA middleware. However, there is no proposal or suggestion with the current systems to provide a HA system which enables multi-vendor inter-operable solutions. Rather, they provide APIs (application program interface) to run various applications in a single middleware entity. At NPF, the focus is to enable multi vendor interoperable mechanisms with the HA middleware itself being formed by several multi vendor HA daemons. HA Daemons are server applications that get started in each control card or line card. For example, when a router or switch is started (booted up or powered up), the operating system starts each process as part of an initial routine. HA daemons are one such process that is started automatically in each control or line card.        
Applications like VoIP and other services require per hop behaviour processing and these network elements need to maintain states. When a network element fails, there should be an alternative network element that should take the state of a failed network element. At present, there are several proprietary solutions, which provide control card redundancy, line card redundancy or network element redundancy. However, there is no open standard protocol or mechanism that exists for providing control card and line card redundancy mechanisms. Rather, vendors will provide their own redundancy mechanisms and solutions. For network element redundancy, the mechanisms proposed in IETF (internet engineering task force) proposals are coarse and do not take care of all state synchronisations of the application nor do they provide a single system image view. Rather, the mechanisms are mainly targeted for network protocols and not for network services such as VoIP state maintenance. This also requires redesigning the existing applications and does not account for heterogeneous multivendor software and hardware.
CGL (carrier grade LINUX) is mainly targeted for LINUX and proposes the extension to the basic POSIX (Portable Operating System Interface Reference—http://www.pasc.org/#POSIX) system calls and it uses the service availability forum's API and the focus is the same as the service availability forum.
IETF virtual router redundancy protocol (VRRP) is a simple heart beat mechanism to detect the network element failure. It does not provide a single system image. It is a network protocol and does not accommodate check pointing and other event management servers.
Common object request broker architecture (CORBA) is a middleware service that mainly supports network access. CORBA has recently added fault tolerance plug in the components. CORBA provides API implementation and enables interoperable applications. It is applicable to network elements but its fast path processing is limited. Interoperability with different CORBA domains has a lot of issues although IIOP (IIOP—Internet Interoperability protocol Reference;—http://www.omg.org/technology/documents/formal/corba_iiop.htm) enables them to perform such communication that requires complex processing.
There are various network elements from for example Cisco, Juniper and other vendors. However, they do not support multi-vendor and open interface protocols. These solutions require a lot of configuration and the boot-strapping procedure is hard coded and is not flexible.
In summary none of the known systems enable multiple HA servers to be in a single HA middleware that works with heterogeneous HA servers and provides interoperability between multi vendor hardware and software systems.
Embodiments of the present invention seek to mitigate or obviate the problems with the current proposals.